Recently a trend has developed to expand database systems to handle nontraditional data types (e.g. images, text, and audio data). In particular, it has become important to provide database systems that handle user-defined "large objects" (LOBs). LOBs may be much larger than traditional data types. For example, a single LOB may include four gigabytes of data.
Because of their size, LOBs cannot be efficiently handled with the same techniques used to handle traditional data types. For example, conventional database systems consist of one or more clients ("database applications") and a server (a "database server"). When a client requires data, the client submits a query to the server that selects the data. The server retrieves the selected data from a database and returns copies of the selected data to the client that submitted the query. When the selected data items are LOBs, the amount of data that would be returned to the user could be enormous. Consequently, automatically sending an entire LOB would be inefficient and time consuming, particularly when the client is only interested in viewing or updating a relatively small subset of the entire LOB.
LOB data may also be thought of as a file or a stream of characters or bytes. Applications are used to storing and accessing large amounts of data in a file, and the same is expected from LOBs. As in file access, applications require random, sequential piecewise access to LOB data. Also, file operations seldom copy the whole file, and the same behavior is expected of LOB operations.
One approach to allow clients to manipulate sub-portions of a LOB is to cause the database server to maintain state information for each LOB operation. For example, a client can request a small portion of a LOB. The database server returns the specified portion of the LOB to the client, and generates state data to indicate which portion of the LOB was sent to the client. The client may then modify the portion of LOB and send the modified portion of the LOB to the database server. The database server inspects the state data associated with that client to determine which portion of the LOB was updated, and stores the updated LOB data into the appropriate portion of the stored LOB.
Unfortunately, maintaining client state information in the server may result in a significant amount of overhead and presents a scalability problem. For example, a single database server may be concurrently supporting thousands of clients, where each client has been supplied locators for hundreds of LOBs. Under these conditions, the state data that identifies which LOB locators have been supplied to each client could consume an unacceptable amount of server-side memory, while maintenance and access operations on the state data could consume an unacceptable amount of computational resources. The inefficiency of maintaining such state information on the server side is exacerbated by the fact that a large percentage of the locators supplied to the clients may be infrequently or never used by the clients.
Based on the foregoing, it is clearly desirable to provide a mechanism for random piece-wise access to LOBs without requiring the database server to maintain an excessive amount of state information. It is further desirable to provide a mechanism for accessing LOBs that enforces the security rules associated with the column, table and/or view to which a LOB belongs.